[MEDIUM] Stale model override briefly visible to AvailableSessionModels during store-write window

Between the sm.mux.Unlock() on line 931 (after mutating the in-memory session) and the sm.mux.Lock() inside the rollback block, UpdateSession is called without holding sm.mux. Because this is an I/O call, it can take arbitrarily long. During this window, a concurrent GET /api/sessions/:id/models request calls AvailableSessionModels, which acquires sm.mux and reads rs.session.AgentModelOverrides[agentName] — observing the not-yet-persisted (and about-to-be-rolled-back) override.

The code comment says "Roll back in-memory under sm.mux first so concurrent readers never see the half-applied state", but that guarantee doesn't hold: sm.mux is released before the rollback lock is re-acquired, so there is a real window.

Impact: GET /models can transiently report a model override that was ultimately never persisted (because the store write failed). The in-memory state is corrected by the rollback, but any client that polled the endpoint during the window would see an incorrect IsCurrent marker.

Suggested fix: Keep the session mutation and the store write under a single critical section, or (if the I/O overhead is unacceptable) hold the modelSwitch lock long enough that the mutation + store write + any rollback are treated as an atomic unit visible only after the store confirms success. Alternatively, mutate the in-memory session after the store write succeeds, never before.

Non-blocking — Nice fix on the clone-then-persist pattern — this kills the 'picker shows new override that gets rolled back' window. There's a smaller residual window between runtime.SetAgentModel succeeding and the post-UpdateSession sm.mux.Lock(): during that gap the runtime is on the new model but AvailableSessionModels reads the old override from rs.session, so GET /models reports IsCurrent on the previous model while requests already execute against the new one. Strictly less bad than what was fixed (briefly stale, never fictitious). Closing it would mean holding modelSwitch around the GET path — non-trivial. A short doc-comment acknowledging the residual window or a follow-up ticket would be enough. Not a merge blocker.

Nit — hadOverridesMap is only used as the if condition immediately below — inline the check and drop the variable. golangci-lint misses it because the assignment makes it look 'used'.

Question — SessionModelsResponse is a brand-new wire type but lives in pkg/runtime next to ModelChoice. The companion SetSessionModelRequest/SetSessionModelResponse sit in pkg/api. The PR description justifies keeping ModelChoice in pkg/runtime because it pre-existed there — but SessionModelsResponse is new code introduced specifically as the wire envelope. Either move it to pkg/api (consistent with the other request/response types) or move all three to pkg/runtime and explain in pkg/api/types.go why model types are an exception. Mixed placement makes pkg/api incomplete as a 'what's on the wire' reference.

Non-blocking — Already raised by @aheritier in round 2 and not addressed in head. Rollback still uses the request ctx — if the original request was cancelled and that's what caused UpdateSession to fail, the rollback inherits the cancellation. context.WithoutCancel(ctx) (or a fresh background ctx with a short timeout) would protect the recovery path. One-line change with a clear correctness argument; worth fixing now.